Programmable Logic Devices (PLDs) are Integrated Circuits (ICs) that are user configurable and capable of implementing digital logic operations. There are several types of PLDs, including Field Programmable Gate Arrays (FPGAs) and Complex Programmable Logic Devices (CPLDs). CPLDs typically include several function blocks that are based on the well-known programmable logic array (PLA) architecture with sum-of-products logic, and include a central interconnect matrix to transmit signals between the function blocks. Signals are transmitted into and out of the interconnect matrix through input/output blocks (IOBs).
The input/output function of the IOBs, the logic performed by the function blocks and the signal paths implemented by the interconnect matrix are all controlled by configuration data stored in configuration memory of the CPLD. FPGAs include configurable logic blocks (CLBs) arranged in rows and columns, IOBs surrounding the CLBs, and programmable interconnect lines that extend between the rows and columns of CLBs. Each CLB includes look-up tables and other configurable circuitry that is programmable to implement a portion of a larger logic function. The CLBs, IOBs and interconnect lines are configured by data stored in a configuration memory of the FPGA.
PLDs have become popular for implementing various logic functions in electronic systems that, in the recent past, were typically implemented by smaller (<100,000 gates) application specific integrated circuits (ASICs). Such functions include glue logic, state machines, data bus logic, digital signal processors and protocol functions. Early PLDs often provided insufficient capacity to implement these functions, so the significant investment of time and money to design, layout and fabricate an ASIC for these functions was justified.
However, recent advances in semiconductor and PLD technologies have produced PLDs with the necessary speed and capacity to implement these functions in most applications. Because PLDs are relatively inexpensive and can be programmed in as little as a few hours, the expense associated with the design, layout and fabrication of ASICs has become harder to justify. Further, the reprogrammability of many PLDs makes them even more attractive than ASICs because it is possible to update (reconfigure) PLDs, whereas ASICs must be replaced, and expensive new masks generated for the new ASIC designs. As such, there is a trend toward the use of PLDs in place of ASICS in electronic systems.
IEEE Standard 1149.1 and 1a entitled IEEE Standard Test Access Port and Boundary-Scan Architecture, published Oct. 21, 1993 by the IEEE under ISBN 1-55937-350-4 relates to circuitry that may be built into an IC device, such as a PLD, to assist in testing the device as well as testing the printed circuit board in which the device is placed. In addition, IEEE Standard 1149.1 is utilized in some PLDs as a convenient mechanism for transmitting configuration data to the PLD during the programming operation performed prior to normal operation. The mechanism by which IEEE Standard 1149.1 is utilized to program a PLD is well known, and therefore the particulars of this mechanism are not described herein.
FIGS. 1 and 2 show a conventional system 100 utilized to program a target PLD 150 using Boundary-Scan signals. A computer or workstation 110 is programmed with an application (software program) 210 including a programming tool 212 that generates a series of communication bursts in response to programming instructions and configuration data 214. These communication bursts are transmitted over a standard download cable 120 to a programming apparatus 130, and in particular to a signal generator 235, which generates appropriate signals used to program PLD 150. According to the conventional arrangement shown in FIG. 1, programming apparatus 130 uses a Boundary-Scan bus 140 including four signals (Boundary-Scan signals) to control PLD 150 during the programming operation: a test data input signal TDI, a test data output signal TDO, a test mode select signal TMS, and a test clock signal TCK.
Additional connections (not shown) are utilized to apply power and transmit communication control signals between programming apparatus 130 and PLD 150, which also comply with IEEE Standard 1149.1. Similar to transmissions to target PLD 150, data read from PLD 150 during the programming operation is transmitted to programming apparatus 130 on bus 140, and from programming apparatus 130 to application 210 over cable 120.
Download cable 120 utilizes one of a variety of standardized communication mechanisms that are typically available on a standard personal computer or workstation, such as serial (RS232) communications, parallel (i.e., printer type) communications, and Universal Serial Bus (USB) communications. As indicated in FIG. 2, these standardized communication mechanisms use communication ports 216 and 232, which are provided on computer or workstation 110 and programming apparatus 130, respectively. The nature of communications over download cable 120 is dependent on the particular cable type being used. However, to support a wide variety of device types, each cable/port combination introduces its own inefficiencies.
FIG. 3 is a flow diagram illustrating in a simplified manner a communication exchange between application 210 and signal generator 235 of programming apparatus 130 according to conventional methods. The communication exchange involves the process of writing configuration data to PLD 150, and then reading back the configuration data from the PLD to verify that it has been written properly. The actual order and instructions being exchanged are simplified for explanatory purposes.
Referring to the left side of FIG. 3, the programming operation begins with the transmission of a “write data” instruction from application 210 to signal generator 235 on download cable 120 (block 310). In response to this instruction, signal generator 235 generates appropriate Boundary-Scan “write data” signals (block 313) that are transmitted on bus 140 to target PLD 150 for execution (block 315). In addition, a confirmation is sent back from signal generator 235 (block 317) that is transmitted over download cable 120 to application 210.
Upon receiving the confirmation (Yes in block 319), application 210 transmits a data word to signal generator 235 on download cable 120 (block 320). Upon receiving the data word, signal generator 235 shifts in the data word on bus 140 (block 323) that are written in associated programmable cells of PLD 150 (block 325). Again, a confirmation is sent back from signal generator 235 (block 327) that is transmitted over download cable 120 to application 210.
Upon receiving the confirmation (Yes in block 329), application 210 next transmits a “read data” instruction to signal generator 235 over download cable 120 (block 330). In response, signal generator 235 generates appropriate Boundary-Scan “read data” signals (block 333) that are transmitted on bus 140 to target PLD 150 for execution (block 335). In addition, a confirmation is sent back from signal generator 235 (block 337) that is transmitted over download cable 120, which is verified by application 210 (block 337). Finally, the data word is shifted out from PLD 150 (blocks 343 and 345), and then transmitted over download cable 120 to application 210 where it is check (block 349). If the data word is written properly (Yes in block 350), then the programming process proceeds to write and check a subsequent data word. If not, then a retry operation (block 360) is executed during which corrective action is taken.
Due to inherent inefficiencies in each type of conventional download cable 120, a problem with the above conventional method is that a significant amount of transmission time is required to support communications protocol overhead. The communication protocol overhead may be generally described as the required delays between transmissions over cable 120 that are needed to coordinate two-way communication. In general, if two-way communication is performed using a lot of short two-way bursts, such as in the example described above with reference to FIG. 3, then the communication protocol overhead creates communication “bottlenecks” as each communication burst waits for its turn to be transmitted over cable 120. These bottlenecks can significantly increase the length of the PLD programming operation, resulting in low throughput rates that increase the amount of time required to manufacture products utilizing PLDs, which in turn reduces profits earned from these products.
Conventional approaches used to speed cable communications focus on having hardware designers design faster throughput cables, and using the fastest available communication port on the target system. While these conventional approaches suggest higher theoretical throughputs may be possible, in practice the communications protocol overhead and communications packet characteristics of the selected cable work against being able to achieve these high theoretical throughputs.
What is needed is a method and apparatus for reducing manufacturing times of products incorporating PLDs by increasing throughput between a programming tool installed on a computer or workstation and a programming apparatus using a standard download cable.